The major problem is the following: suppose we start from an InfiniteWeightPEPS with the "standard" arrow directions and axis order:

        2
        |
        yᵢⱼ
        | 
        1
        2
        |
    5--Tᵢⱼ--3  1--xᵢⱼ--2
        | ↘
        4   1

After rotl90, the axis order of new x-weights needs to be reversed. For fermions, this will make the odd sector of x-weights negative (if it is done with permute, not transpose). Then I need to twist one of the axes of x-weights to make the weight elements positive. This should be cancelled by another twist on the vertex tensors. But if I define rotl90 in this way, I found that applying it 4 times will not go back to the original peps because of the extra twists on the virtual indices of vertex tensors. This is shown in the new test file iwpeps_rotation.jl.

Do you have suggestions on this? @sanderdemeyer Could you also please think about it? You may be the one who uses InfiniteWeightPEPS most often besides me 😄

The problem lies indeed in the added twists, but this does not necessarily have to be a problem. For example, an InfinitePEPS is invariant under twists on 'either side', so e.g. calling twist!(peps[row,col], [2 4], twist!(peps[row,col], [3 5], or twist!(peps[row,col], [2 3 4 5] will not change the physical state, since the twists cancel on either side of the PEPS tensor.

This is also what happens here in the tests. Even though compose_n(rotl90, 4)(obj) ≈ obj returns false, if you convert compose_n(rotl90, 4)(obj) to an InfinitePEPS, it will return the same expectation values as InfinitePEPS(obj). This can be easily checked with a random two-site operator. This gauge freedom is inherent. So I can try to help you in defining the rotations in such a way that the tests run, but in terms of getting physical results, the current implementation is probably fine.

This is a choice we have to make. I could get behind wanting a different implementation such that the tests run. If we do decide to keep the current implementation, we could add checks on the expectation values, rather than the PEPS tensors themselves.

I'm aware that the physical state is indeed the same. I just wonder if there is a way that can keep the InfiniteWeightPEPS itself invariant without a further gauge transformation. After all, == for InfinitePEPS is defined without gauge freedom, so I want to mimic this for InfiniteWeightPEPS as well.

If this turns out to be too cumbersome for InfiniteWeightPEPS, then maybe we just modify absorb_weight in such a way that InfinitePEPS(pepswt1) == InfinitePEPS(pepswt2) if pepswt1, pepswt2 have the same internal arrow directions, and only differ by some twists that cancel each other.

I'm not entirely sure that asking for elementwise equality is necessary (or even always possible). In some sense, I'm slightly confused that twists appear here at all, and I would guess that you could simply permute all tensors, and the state would still be unchanged (I didn't check this). After this, you could use the flip function to restore the arrows, but in an ideal world this wouldn't even be necessary.

In any case, as @sanderdemeyer said, I think checking that expectation values of random operators are left unchanged is more meaningful than trying to make the tensors be exactly equal.

@lkdvos The twists is because I want to keep the direction (axis order) of the weight matrices. For example, after rotl90, the weight axes order become

          2
          |
          y
          |
          1
2 -- x -- 1

I need to permute the new weights back to 1 -- x -- 2, resulting in negative elements for fermions. But these weights are rough analogs of the Schmidt weights in 1D MPS, so I want to keep the weight elements positive. It can also make it easier to absorb the square roots of the weights into the vertex tensors. In principle I can lift the positiveness constraint, but I just feel uncomfortable about doing it.

About the flip, indeed one approach is we restore the internal arrow directions after rotation, so I don't need to further modify absorb_weight. This is already enough for me when doing SU (I only need states in which the arrows are ← or ↓). I'm just thinking whether we can be more general to handle all kinds of arrow directions. Anyway, if you are OK to always restricting the arrows to be ← or ↓ in InfiniteWeightPEPS, we can take this approach, and life will be much easier for me.

@sanderdemeyer I'll try implementing the rotation that does not rotate the arrows together with the state this week, and add the constraint that virtual arrows in InfiniteWeightPEPS can only be ← or ↓. What do you think of this approach?

@Yue-Zhengyuan This is perfect for me. It feels like the safest choice to always impose that an InfinitePEPS or InfiniteWeightPEPS has arrows ← or ↓ on the virtual legs.

Codecov Report

Attention: Patch coverage is 92.77108% with 6 lines in your changes missing coverage. Please review.

@sanderdemeyer Could you please take a look and see if there are further improvements you want?

BTW, after this is merged, I'll use rotation instead of mirroring to swap x/y directions in SU. I find this leads to a more stable result in some of my use cases. Then mirror_antidiag will be used nowhere in PEPSKit, and I plan to remove it then.

I had hoped that we could recover the same state (without the twists) if we would properly distinguish between inv=true and inv=false flips. Even though this is theoretically possible, this would again require us to relax the constraint to have positive weight elements. Since I agree with you that this is not the best idea, I am okay with keeping the current implementation.

In conclusion, I think we can merge this.

properly distinguish between inv=true and inv=false flips

I did consider adding a kwarg to the rotation functions to specify whether inv=true or inv=false flips are used. But in the end I think this is too much, and makes repeated application of rotations more confusing.

@lkdvos Should we update the format check with JuliaFormatter v2 (currently v1 is being used)? They give different result for a few files.

I am holding off on that for now since it indeed gives different results for a few files.
My biggest annoyance with the new vesion is that it transforms this:

function myfunction(args..., ::Type{T}=Float64, ...)
end

into this:

function myfunction(args..., (::Type{T}=Float64), ...)

which I think is just silly. I'm happy to rediscuss formatters, but this really has to be in a separate single PR so the formatting changes don't get mixed up with actual coding changes

I've undone the v2 formatting changes.